This PR adds 3D (Z) coordinates support to GeoJSON reader and writer.

It includes a new method setOutputDimensions for the writer, similar to the WKT one, but which (for now ?) only accepts values 2 or 3. Support for M coordinates was left out of this PR as it is discouraged by the specification, and would require more thinking about special cases. Any M values in the coordinates being serialized are therefore ignored (like the Z values were before this PR).

Considering the handling of mixed 2D/3D coordinates and NaN values isn't clearly specified, I made some decisions in that regard which are of course all open for debate:

• Mixed coordinates are allowed. If a coordinate sequence contains any Z value, the missing coordinates in the parsed geometry will be NaN. This behavior is different than PostGIS and OGR, which both interpret missing Z coordinates as 0:

SELECT '{"type":"LineString","coordinates":[[-117, 33], [-116, 34, 4]]}'::geometry;
-- LINESTRING(-117 33 0,-116 34 4)

>>> ogr.CreateGeometryFromJson("{\"type\":\"LineString\",\"coordinates\":[[-117, 33], [-116, 34, 4]]}")
LINESTRING Z (-117 33 0,-116 34 4)

As a side note, PostGIS also converts any null value in a GeoJSON string as 0:

SELECT '{"type":"Point","coordinates":[1,null,null]}'::geometry;
-- POINT(1 0 0)

But OGR will instead consider it an invalid input:

>>> ogr.CreateGeometryFromJson("{\"type\":\"Point\",\"coordinates\":[0, null, null]}")
None

• NaN Z values are never included in the coordinate array, regardless of the writer output dimension. This choice was made to facilitate interoperability and round-trips within GEOS, as parsing a GeoJSON string with nulls will result in a ParsingError... But maybe this is something we want to change, even though it would deviate from the standard which states that the coordinates GeoJSON member should only contain numbers.